1. Field of the Invention
The present invention generally relates to a method for SIP (Session Initiation Protocol) proxy failover in a SIP telecommunication network.
FIG. 1 schematically represents an example of a classical SIP telecommunication network SIPN comprising two proxies P1, P2 and a domain name server DNSR. Telephone terminals respectively comprise user agents SIPUA1, SIPUA2, etc, and are linked to this SIP network via Ethernet links.
All SIP user agents SIPUA1, SIPUA2, etc, are registered to a same SIP domain, by using the procedures defined by standards RFC3261 and RFC3263, and especially Domain Name System (DNS) resolution. For instance, the user agent SIPUA1 has registered to the proxy P1, and the user agent SIPUA2 has registered to the proxy P2. For registering in a proxy, a user agent makes a “DNS request” to a DNS server in order get a list of proxy addresses, with a priority ranking, then it selects the proxy address having the highest priority in this list and registers to it. Once registered, it sends subsequent requests to that proxy (unless DNS server configuration is changed), in particular it sends requests to set up calls.
A SIP domain is generally managed by a set of proxies and these proxies are redundant, so that each proxy provides a failover function in case another one is shutdown (for maintenance purpose for example). For instance, if the proxy P1 is shutdown for maintenance, then the SIP User Agent SIPUA1 is supposed to switch to the backup proxy P2. But the SIP user agent SIPUA1 is not immediately aware, by SIP protocol means, that the proxy P1 is shutdown.
FIG. 2 illustrates the failover from the proxy P1 to the proxy P2 in this exemplary SIP telecommunication network SIPN. When the proxy P1 is shutting down, then the proxy P2 is taking over in order to serve all the user agents in the domain. When a user starts his/her SIP telephone, the SIP user agent SIPUA1 of this telephone makes the following steps:                Step 20: It send a DNS request to the DNS server DNSR, according to standard RFC3263, in order to solve the domain name.        Step 21: The DNS server DNSR responds by a DNS response containing proxy addresses respectively pointing to the proxy P1 in first priority and to the proxy P2 in second priority.        Step 22: Some time later, the proxy P1 shuts down.        Step 23: Some time later, the user of this telephone calls another telephone user. The user agent SIPUA1 again sends a DNS request to the DNS server DNSR, according to standard RFC3263, in order to solve the domain name.        Step 24: The DNS server DNSR responds by a DNS response containing proxy addresses respectively pointing to the proxy P1 in first priority and to the proxy P2 in second priority, because it is not aware of the shutdown of the proxy P1.        Step 25: Then the user agent SIPUA1 sends a message “INVITE sip:bob@example.com” to the proxy P1, because it has the highest priority. The proxy P1 fails to establish a session because it is shutdown. It does not respond at all. The terminal is waiting for a response.        Step 26: In the user agent SIPUA1, a timer B (request timeout, see timer reference in RFC3261) expires after a predetermined time.        Step 27: Then the user agent SIPUA1 sends a message “INVITE sip:bob@example.com” to the proxy P2, that has a second priority in the list of proxy addresses received from the domain name server DNSR.        Step 28: The proxy P2 responds by a message “403 Forbidden” because the user agent SIPUA1 is not registered in the proxy P2.        Step 29: The user agent SIPUA1 sends an acknowledgement message “ACK” to the proxy P2.        
The call establishment has not been possible because the SIP User Agent SIPUA1 is not registered to proxy P2. This registration will occurs later, at the registration refresh time (according to RFC3261 registration refresh). So a call will be possible after the refresh time, but this delay may be long (several minutes).
2. Description of the Prior Art
The best existing solution is described in RFC3261, RFC3263, and RFC5626 section 4.5:                RFC3261 defines a refresh time (named “expire”) at which a SIP user agent tries to register again to the same proxy.        RFC5626 defines an algorithm to accelerate the recovery in case a proxy is not reachable.        RFC3263 sends a “DNS SRV” message to communicate the list of backup proxies.        
The sip user agent must use this list of proxies (with a priority ranking) to switch to a recovery proxy.
This known solution is not good enough, because the recovery time is too long, this time should be as short as possible. Let's try to estimate this time:                When an INVITE message is sent to proxy P1, a timer B is started and will expire before the shutdown is detected. By default, the timer B (cf. RFC3261) lasts 32 seconds.        When a second INVITE message is sent to the proxy P2, it is rejected because it is not registered to the proxy P2. To register again, it may last, at worst, the expire time which can be very long (several minutes).        
Another known solution, illustrated by FIG. 3, comprises a common database CDB where all the proxies P1, P2, of a domain, store the registration addresses of all the user agents. However if a SIP user agent, SIPUA 3 for instance, is behind a router R comprising a network address translator (commonly abbreviated “NAT”), this solution doesn't work anymore: Actually, the network address translator assigns two different transport addresses (IP address+port), respectively 10.0.0.1:3333 and 10.0.01:2222 for instance, when an a message is forwarded to the proxy P2, and when a message is forwarded to the proxy P1. So the registration address (10.0.0.1:3333) used for reaching the proxy P2 cannot be re-used for reaching the proxy P1, in case of failure of the proxy P2, though this registration address (10.0.0.1:3333) has been registered in the common data base DB.
Thus, there is a need to provide a technical solution for providing a quick SIP proxy failover. It is peculiarly important when users are waiting for emergency phone calls to be set up.
This problem can be solved by applying the method according to the invention.